Method for providing ims support for enterprise pbx users

ABSTRACT

An architecture and procedures by which an NGN can provide the following capabilities to an NGCN user: basic terminating service in the peering model; enhanced terminating services in the peering model; enhanced originating services in the peering model; and roaming service in the subscription and peering models. All capabilities are provided in an easily scalable manner via provisioned subscriber data and small modifications to existing IMS procedures. In one embodiment, an NGN is configured among the external networks to receive all SIP requests intended for the NGCN users of an NGCN interconnected to the NGN via the peering model (this NGN is the trunking home NGN), and the NGN forwards these requests to the NGCN for handling using request retargeting.

This application is a divisional of U.S. patent application Ser. No.12/235,680, filed Sep. 23, 2008.

BACKGROUND OF THE INVENTION

This invention relates to a method for IMS (Internet Protocol MultimediaSubsystem) support for enterprise PBX (Private Branch Exchange) userroaming, originations and terminations. While the invention isparticularly directed to the art of telecommunications, and will be thusdescribed with specific reference thereto, it will be appreciated thatthe invention may have usefulness in other fields and applications.

By way of background, there has been considerable work done in TISPAN(Telecoms & Internet converged Services & Protocols for AdvancedNetworks) and 3GPP (3rd Generation Partnership Project) to specify howto support NGCN (Next Generation Corporate Network) users within an NGN(Next Generation Network). An NGN is an operator network based on IMS.Each NGCN is comprised of one or more IP (Internet Protocol) PBX systemswith IP interconnect to an NGN, which is normally referred to asbusiness trunking or SIP trunking.

Currently, there are two NGCN/NGN interconnect models—the subscriptionmodel and the peering model. In the subscription model, the NGCNinterconnects to the NGN via the Gm reference point (a SIP-basedreference point normally shown between the user equipment (UE) and theProxy-Call Session Control Function (P-CSCF)). The NGCN registers intothe NGN on behalf of all NGCN users, which receive some services fromtheir NGCN as well as receiving other services from the NGN IMS (IPMultimedia Subsystem) according to the provisioned application serversand filter criteria. The subscription model clearly defines how the NGNprovides basic call originating and terminating services plus enhancedoriginating and terminating services to the NGCN users. There iscurrently no agreed standard for how the NGN in the subscription modelprovides roaming service to an NGCN user. In the peering model, the NGCNinterconnects to the NGN via an inter-IMS interface (typically via anInterconnect Border Control Function (IBCF)) but does not register intothe NGN on behalf of its users. The peering model clearly defines howthe NGN provides basic transit/routing services for SIP requestsoriginating in the NGCN. There is currently no agreed standard for howthe NGN in the peering model provides basic terminating service,enhanced originating or terminating services, or roaming service to anNGCN user.

It is evident that there is a need for the NGN to provide variouscapabilities, including (1) basic call terminating service in thepeering model, (2) enhanced terminating services in the peering model,(3) enhanced originating services in the peering model, and (4) roamingservice in the subscription and peering models. The existing solutionsand limitations are described generally below.

(1) The NGN interconnected to an NGCN in the peering model is defined asthe trunking home NGN. The trunking home NGN is configured as theinitial destination for all terminating requests to an NGCN user. Thetrunking home NGN receiving a request for an NGCN user must somehowretarget terminating SIP requests to the NGCN. The originating networkforwards a SIP request to the trunking home NGN as a result of the DNS(Domain Name System) query, which identifies the trunking home NGN asthe target for the request. Since the NGCN does not register on behalfof its users with the NGN in the peering model, it is unclear how theNGN can retarget the request to the NGCN. Existing approaches involvethe use of SIP proxies to retarget such a request to the NGCN based onprovisioned data.

Another possibility is to configure a private DNS within the NGN toretarget the request to the NGCN. Neither approach scales well if thereare a significant number of interconnected NGCNs. Either way, the NGNmust have special routing procedures and provision special routing datafor each NGCN interconnection. It would be preferable if the IMS NGNcould instead use generic IMS procedures driven by provisionedsubscriber data to perform the request retargeting in an easily scalablemanner.

(2) To provide enhanced terminating services in the peering model, inaddition to the procedure in item 1 above, the NGN would have to alsoprovision a special application server in the routing path ofterminating requests to provide enhanced services for these requests. Soat least two entities would need to be provisioned on the routing pathfor each NGCN interconnection. Since fixed application servers wouldneed to be allocated to provide these terminating services, it isdifficult to reuse application servers interconnected via standard IMSinterfaces, and there is less ability to assign traffic to applicationservers as usage and the number of interconnected NGCNs grows.

(3) By configuring the trunking home NGN as the next destination for alloriginating requests from the NGCN in the peering model, the NGN canprovide basic transit/routing services to the NGCN user. But to provideenhanced originating services to this NGCN user, the NGN would have toalso provision a special application server in the routing path oforiginating requests to provide enhanced services for these requests.Since fixed application servers would need to be allocated to providethese originating services, it is difficult to reuse application serversinterconnected via standard IMS interfaces, and there is less ability toassign traffic to application servers as usage and the number ofinterconnected NGCNs grows.

(4) For roaming NGCN users, the visited NGN is defined as the networkinto which the NGCN user is roaming, and to which the NGCN user isdirectly connected. When attempting to register for service, the NGCNuser sends its registration request via the visited NGN to the registrarname provisioned in the device. The roaming home NGN is defined as theregistrar for the NGCN user and the network to which registrationrequests from the NGCN user are first routed by the visited NGN. Thevisited NGN forwards a SIP registration request to the roaming home NGNas a result of DNS, which identifies the roaming home NGN as the SIPregistrar. Analogously to item 1 above, the roaming home NGN mustsomehow retarget SIP registration requests to the NGCN to gain access toservices provided by the NGCN. Existing approaches to forwarding the SIPregistration request from the roaming home NGN to the NGCN involve theuse of SIP proxies to retarget such a request to the NGCN based onprovisioned data. Another possibility is to configure a private DNSwithin the NGN to retarget the request to the NGCN. Neither approachscales well if there are a significant number of interconnected NGCNs.Either way, the NGN must have special routing procedures and provisionspecial routing data for each NGCN interconnection. It would bepreferable if the IMS NGN could instead use generic IMS proceduresdriven by provisioned subscriber data to perform the request retargetingin an easily scalable manner. If the NGCN also registers on behalf ofits users to the trunking home NGN, as in the subscription model, it isalso not clear how to distinguish between registration requests from thevisited NGN and the NGCN.

The present invention contemplates a new and improved method thatresolves the above-referenced difficulties and others.

SUMMARY OF THE INVENTION

The disclosed invention defines an architecture and the procedures bywhich an NGN can provide the following capabilities to an NGCN user:

Basic terminating service in the peering model: An NGN is configuredamong the external networks to receive all SIP requests intended for theNGCN users of an NGCN interconnected to the NGN via the peering model(this NGN is the trunking home NGN), and the NGN forwards these requeststo the NGCN for handling in an easily scalable manner using requestretargeting driven by provisioned subscriber data and smallmodifications to existing IMS procedures.

Enhanced terminating services in the peering model: An NGN is configuredamong the external networks to receive all SIP requests intended for theNGCN users of an NGCN interconnected to the NGN via the peering model,and the NGN applies a set of agreed services using NGN ASs (applicationservers) to each request before forwarding to the NGCN for handling. Byrouting requests to an S-CSCF before retargeting to the NGCN, the S-CSCFcan use provisioned unregistered filter criteria to access theapplication servers providing the terminating services based on existingIMS procedures.

Enhanced originating services in the peering model: The NGCN isconfigured to forward all originating requests to an NGN (the trunkinghome NGN) via the peering model. The NGN allocates an S-CSCF for NGCNusers provisioned for originating services and forwards the originatingrequests to the S-CSCF so that it can use provisioned unregisteredfilter criteria to access the application servers providing theoriginating services based on existing IMS procedures. The provisioningof data for the NGCN users and forwarding to the S-CSCF for services isperformed in an easily scalable manner based on provisioned subscriberdata and small modifications to existing IMS procedures.

Roaming service in the subscription and peering models: An NGN isconfigured among the external networks as the roaming home NGN toreceive a SIP REGISTER request from an NGCN user that has roamingcapability. While the NGCN associated with the NGCN user may beinterconnected to the trunking home NGN via the peering model or thesubscription model, the NGCN is interconnected to the roaming home NGNonly via the peering interface (inter-IMS). The roaming home NGN may ormay not be the same as the trunking home NGN, regardless of which modelis used to interconnect the trunking home NGN. When the NGCN userattempts to roam to this NGN or another NGN (the visited NGN), thevisited NGN forwards the received SIP registration request from the NGCNuser device to the roaming home NGN, and the roaming home NGN thenforwards the registration request to the NGCN and establishes a pathbetween the NGCN user and the NGCN for handling of subsequentoriginating and terminating requests. The NGN forwarding of theregistration request is performed in an easily scalable manner usingrequest retargeting driven by provisioned subscriber data and smallmodifications to existing IMS procedures.

In accordance with an aspect of the invention, a method of providingcall terminating service in a Next Generation Network (NGN) is provided.The method comprises: assigning to each user in a Next GenerationCorporate Network (NGCN) a public user identity (PUID) that is known toa trunking home NGN and has a domain assigned to the trunking home NGN;and provisioning each public user identity (PUID) assigned to an NGCNuser within a subscriber database with an alternate contact, wherein thealternate contact is an address for an NGCN server to which the NGCNuser registers.

In accordance with another aspect of the invention, the method ofproviding call terminating service further comprises: receiving aterminating request for a PUID; sending a query to the subscriberdatabase using the PUID of the NGCN user; determining whether thetrunking home NGN shall provide originating or terminating services tothe PUID and whether the PUID is associated with any other privateidentity. Where the trunking home NGN shall not provide originating orterminating services to the PUID and the PUID is not associated with anyother private identity, an alternate contact is forwarded in a responseto an Interrogating Call Session Control Function (I-CSCF). Next, adetermination is made as to whether an alternate contact for the PUIDhas been included in the response and where an alternate contact hasbeen included in the response, the terminating request is forwarded tothe alternate contact.

In accordance with yet other aspect of the invention, the method ofproviding enhanced call terminating services may further comprise: thetrunking home NGN assigning an entry point into itself for a terminatingrequest to an NGCN user where this entry point is the same entry pointused for a terminating request to a subscriber of the same NGN.Optionally, the profile data for the PUID may include a forwardingoption, which is an indication of whether a Call Session ControlFunction is to use loose-routing or retargeting when forwarding requeststo the alternate contact. Also, the method may include: where thetrunking home NGN shall provide originating or terminating services tothe PUID, forwarding Serving Call Session Control Function (S-CSCF)information in a response to an Interrogating Call Session ControlFunction (I-CSCF), forwarding the request to the S-CSCF, downloading aprofile for the PUID, forwarding the request to any application serversidentified by filter criteria to apply appropriate terminating services;and forwarding the terminating request to the alternate contact vialoose routing or retargeting.

In accordance with yet another aspect of the invention, a method ofproviding enhanced call originating service in a Next Generation Network(NGN) is provided. The method comprises: assigning to each user in aNext Generation Corporate Network (NGCN) a public user identity (PUID)that is known to a trunking home NGN and has a domain assigned to thetrunking home NGN; and provisioning a subscriber database with anoriginating services flag associated with the PUID of each NGCN userwhose NGCN is interconnected via a peering model and who is to receiveenhanced originating services.

In accordance with yet another aspect of the invention, the method ofproviding enhanced call originating service further comprises: receivingan originating request from an NGCN user having a PUID; and determiningwhether the originating request is a candidate for originating servicesaccording to local policy. Where the originating request is a candidatefor originating services, a query is sent to a subscriber database usingthe PUID of the NGCN user. The originating services flag for the PUID isforwarded in a response to an Interrogating Call Session ControlFunction (I-CSCF); and where the response also includes Serving CallSession Control Function (S-CSCF) information for the PUID, the requestis forwarded to the appropriate S-CSCF. The trunking home NGN may be anIMS providing enhanced originating services to an NGCN user according toa peering model. Also, the local policy may specify that all originatingrequests are candidates, that all originating requests received at aspecific IBCF or I-CSCF are candidates, or that all requests from aspecific NGCN server are candidates.

In accordance with yet another aspect of the invention, a method ofproviding roaming service for a user in a Next Generation Network (NGN)is provided. The method comprises: assigning to each of user in a NextGeneration Corporate Network (NGCN) a Session Internet Protocol (SIP)registrar name whose domain is assigned within a public Domain NameSystem (DNS) to a roaming home NGN; and provisioning each public useridentity (PUID) assigned to an NGCN user with roaming capability withina database with an alternate registrar, wherein the alternate registrarcontains the address at which the NGCN server can be reached withregistration requests.

In accordance with yet another aspect of the invention, the method ofproviding roaming service further comprises: receiving a registrationrequest for a PUID; determining whether the PUID has roaming capability.Where the PUID has roaming capability, an alternate registrar instead ofServing Call Session Control Function (S-CSCF) data is forwarded in aresponse. The registration request is forwarded to the alternateregistrar instead of an S-CSCF. The method may further comprisepopulating SIP path and service route headers so that subsequentoriginating and terminating requests follow the same path between theNGCN and the roaming user. In addition, the same domain may resolve tothe NGCN itself within the NGCN private DNS to enable the NGCN user toregister for services from its NGCN when not roaming and a roaming homeNGN may be an IMS that assigns an entry point into itself for SIPregistration requests from roaming NGCN users in visited NGNs into whichthey roam and the entry point is the same one used by roaming NGN users.

Further scope of the applicability of the present invention will becomeapparent from the detailed description provided below. It should beunderstood, however, that the detailed description and specificexamples, while indicating preferred embodiments of the invention, aregiven by way of illustration only, since various changes andmodifications within the spirit and scope of the invention will becomeapparent to those skilled in the art.

DESCRIPTION OF THE DRAWINGS

The present invention exists in the construction, arrangement, andcombination of the various parts of the device, and steps of the method,whereby the objects contemplated are attained as hereinafter more fullyset forth, specifically pointed out in the claims, and illustrated inthe accompanying drawings in which:

FIG. 1 is a diagram of the business trunking reference architecture;

FIG. 2 illustrates NGCN user roaming scenarios;

FIG. 3 is a flowchart describing the provision of basic and enhancedterminating NGN services to NGCN users in the peering model;

FIG. 4 is a flowchart describing the provision of enhanced originatingNGN services to NGCN users in the peering model;

FIG. 5 is a flowchart describing the provision of roaming NGN service toNGCN users;

FIG. 6 illustrates a call flow for a Register request from an NGCN userthat is roaming to another NGN;

FIG. 7 illustrates a call flow for call origination from an NGCN userroaming to another NGN;

FIG. 8 illustrates a call flow for normal NGCN origination forpeering-based business trunking;

FIG. 9 illustrates a call flow for normal NGCN origination forsubscription-based business trunking;

FIG. 10 illustrates a call flow for call termination to an NGCN userthat is roaming to another NGN;

FIG. 11 illustrates a call flow for a first alternative for normaltermination to an NGCN user for peering-based business trunking;

FIG. 12 illustrates a call flow for a second alternative for normaltermination to an NGCN user for peering-based business trunking; and

FIG. 13 illustrates a call flow for normal termination to an NGCN userfor subscription-based business trunking.

DETAILED DESCRIPTION

It is expected that most NGCNs will use an NGN as the interface toexternal networks to provide these roaming, originating and terminatingservices. By having a single NGN as the interface to external networks,the NGCN can leverage a single trust relationship with its NGN toestablish a transitive trust relationship with all of the externalnetworks with which its NGN has trust relationships, according to theIMS trust model. Thus the NGCN can benefit from the identity assertion,header filtering, traffic control, routing and other services that itsNGN can offer via transitive trust relationships with other NGNs thatthe NGCN would otherwise have to realize on its own. In addition to thebenefits of the trust relationship with an NGN, the NGCN also receivesIP based trunking services, such as interconnect to the PSTN and otherpeering SIP networks, routing of 8xx and LNP (local number portability)calls, etc.

Referring now to the drawings wherein the showings are for purposes ofillustrating the exemplary embodiments only and not for purposes oflimiting the claimed subject matter, FIG. 1 provides a view of a systeminto which the presently described embodiments may be incorporated. Asshown generally, FIG. 1 includes an NGN 10 (Service Provider's Network)and an NGCN 12 (Enterprise Network). The NGN 10 includes a set of SIPServers known as Call Session Control Function (CSCF) 14, a BusinessTrunking (BT) Application Server (AS) 16, a Media Gateway ControlFunction/Media Gateway (MGCF/MGW) 18 connected to the Public SwitchedTelephone Network (PSTN) 20, an IBCF 22 connected to the PeeringVoIP/NGN 24, and an Edge SIP Server 26 connected to the NGCN 12. TheNGCN 12 includes a SIP PBX 28 (acting as a SIP Proxy Server) and anynumber of PBX users 30 (SIP phones, acting as SIP User Agent (UA)).

The CSCF 14 is a central component to signaling and control within theIMS network. Subdivided into three separate parts, the CSCF isresponsible for signaling via Session Initiation Protocol (SIP) betweenthe Transport Plane, Control Plane, and the Application Plane of IMS.The CSCF consists of the Proxy CSCF (P-CSCF), Interrogating CSCF(I-CSCF), and the Serving CSCF (S-CSCF).

The business trunking interface (a.k.a. SIP trunking interface) betweenthe SIP PBX 28 and the Edge SIP Server 26 provides the business trunkingconnectivity and services to the NGCN 12. In this view, the NGN 10 isthe Trunking Home network for the NGCN 12.

Two models are supported over the Business Trunking interface:

In the subscription model, the Edge SIP Server 26 plays the role of aProxy-Call Session Control Function (P-CSCF). The SIP PBX 28 registerswith the NGN on behalf of the PBX users 30. Calls originated from theNGCN 12 to a public network are forwarded to the Edge SIP Server 26 bythe SIP PBX 28. Calls terminated from a public network to the NGCN 12are routed by the Edge SIP Server 26 to the SIP PBX 28.

In the peering model, the Edge SIP Server 26 plays the role of an IBCF.The SIP PBX 28 does not register with the NGN. Calls originated from theNGCN 12 to a public network are forwarded to the Edge SIP Server 26 bythe SIP PBX 28. Calls terminated from a public network to the NGCN 12are routed by the Edge SIP Server 26 to the SIP PBX 28.

When being served within the Enterprise network 12, the SIP phones 30register with the PBX 28.

The PBX SIP Proxy Server 28 appears as an NGN user to the NGN/IMS 10.The PBX SIP Proxy Server 28 differs from the “normal” UE in followingaspects: (a) it handles many PBX phones; (b) it originates andterminates calls on behalf of PBX phones; and (c) it may register onbehalf of PBX phones.

PBX Directory Numbers (DN) that have Direct-In-Dialing ability areassigned with an IMS Public User Identity (PUID), or wild-carded PUID tocover a contiguous range of DNs.

To enable service while outside the Enterprise network 12, several NGCNroaming scenarios for PBX user X are illustrated in FIG. 2:

1. PBX User X roams to NGCNy connected to trunking home NGN A (notconsidered);

2. PBX User X roams to trunking home NGN A, which has an SLA (servicelevel agreement) with NGN A;

3. PBX User X roams to a visited NGN B, which has an SLA with NGN A; and

4. PBX User X roams to roaming home C (not shown in figure).

In scenarios 2, 3 and 4, NGCN User X (a.k.a. PBX User X), while roamingin NGN A, B or C, respectively, must be able to register with its homeNGCN to receive services from its home NGCN.

Now, let us take the capabilities noted earlier one at a time.

Referring to FIG. 3, in the first case (basic call terminating servicein the peering model) and the second case (enhanced terminating servicesin the peering model), the NGCN assigns to each of its users a publicidentity that is known to the trunking home NGN and has a domainassigned to the trunking home NGN (101). The trunking home NGN assignsan entry point into itself for a terminating request to an NGCN user.This entry point is the same entry point used for a terminating requestto a subscriber of the same NGN (the I-CSCF or IBCF).

Following standard IMS procedures upon receipt of a terminating request,the I-CSCF queries the HSS with the contents of the Request-URI (102).

According to a new procedure, the HSS determines whether the trunkinghome NGN shall provide originating or terminating services to the PUID(or wildcard PUID) corresponding to the Request-URI and whether the PUIDis associated with any other private identity (i.e., the PUID is shared)(103). If the HSS determines that the trunking home NGN shall provideservices to the PUID or that the PUID is associated with any otherprivate identity, then the HSS will include S-CSCF information in theresponse to the I-CSCF according to normal procedures (i.e., theresponse includes either the name of an S-CSCF assigned to the PUID orcriteria by which to select an S-CSCF) (104). The HSS determines thatthe NGN shall provide services to the PUID if either originating orterminating unregistered filter criteria are provisioned for the PUID.The HSS must consider both originating and terminating services becauseit cannot distinguish between queries received in this procedure and theone received in FIG. 4. Otherwise, according to a new procedure, the HSSwill not return S-CSCF information but will instead return analternate-contact in the response to the I-CSCF, if this new piece ofHSS data is provisioned as an element of the profile data associatedwith the PUID or wildcard PUID associated with the Request-URI. Thealternate-contact is an address for the NGCN server to which the NGCNuser registers. Optionally, the profile data in the HSS may also includea forwarding-option, which is an indication of whether CSCFs are to useloose-routing or retargeting when forwarding requests to thealternate-contact. If present, the HSS will also return theforwarding-option in the response to the I-CSCF.

According to a new procedure, the I-CSCF determines whether the HSS hasreturned S-CSCF information or an alternate-contact in its response(106). If the I-CSCF determines the HSS has returned no S-CSCFinformation but has included an alternate-contact in its response, thenthe I-CSCF forwards the terminating request to the alternate-contact(optionally routing the request via an IBCF according to standard IMSrouting procedures) (107).

Two options (loose-route or retarget) can be used by the I-CSCF toforward the terminating request to the alternate-contact, based oneither local policy or the forwarding-option received from HSS. In thecase of loose-routing, the I-CSCF will populate a Route header with thealternate-contact, with the option to route via an IBCF, leaving theRequest-URI intact. In the case of retargeting, the I-CSCF will rewritethe host portion of the Request-URI with the alternate-contact.

When the NGCN server (alternate-contact) receives the terminatingrequest, it performs any provisioned services and forwards it to theregistered NGCN user according to normal procedures. The NGCN user maybe registered within the NGCN or while roaming in another network. Thatconcludes this branch of the procedure, supporting only the first case(basic call terminating service in the peering mode).

Otherwise, if the HSS returns S-CSCF information to the I-CSCF accordingto normal procedure, the I-CSCF forwards the request to the assignedS-CSCF (108).

Also according to normal procedures, the S-CSCF downloads the profilefor the PUID from the HSS (if it has not already been downloaded) andforwards the request to any application servers identified by filtercriteria, to apply appropriate terminating services (109). After allapplication servers have been visited by the request and if no calldiversion service has been applied to the request, the S-CSCF thennormally forks the request to any registered contacts for the PUID,although this normal procedure is modified as follows.

According to a new procedure, the profile downloaded by the S-CSCF willinclude the alternate-contact, which is understood to be an unregisteredcontact for the PUID. The alternate-contact is an address for the NGCNserver to which the NGCN user registers. Optionally, the profile data inthe HSS may include a forwarding-option, which is an indication ofwhether CSCFs are to use loose-routing or retargeting when forwardingrequests to the alternate-contact. The profile may also include a qvalue for the alternate-contact so that it can be assigned a relativepriority for forking compared to registered contacts for the PUID.

The S-CSCF then forks the request to registered contacts and theunregistered contact (the alternate-contact) (110). As a special case,if there are no registered contacts, the S-CSCF just forwards therequest to the alternate-contact. Two options (loose-route or retarget)can be used by the S-CSCF to forward the terminating request to theunregistered contact (alternate-contact), based on either local policyor the forwarding-option in the profile. In the case of loose-routing,the S-CSCF will populate a Route header with the alternate-contact, withthe option to route via an IBCF, leaving the Request-URI intact. In thecase of retargeting, the S-CSCF will rewrite the host portion of theRequest-URI with the alternate-contact.

When the NGCN server (alternate-contact) receives the terminatingrequest, it performs any provisioned services and forwards it to theregistered NGCN user according to normal procedures. The NGCN user maybe registered within the NGCN or while roaming in another network. Thatconcludes this branch of the procedure, supporting both the first case(basic call terminating service in the peering mode) and the second case(enhanced terminating services in the peering model).

With small changes to existing IMS procedures, this invention allows forapplication of services and/or proper routing of terminating requests tothe NGCN based only on provisioned subscriber data in a highly scalablemanner.

Referring now to FIG. 4, in the third case (enhanced originatingservices in the peering model), the NGCN assigns to each of its users apublic identity that is known to the trunking home NGN (201). Thetrunking home NGN is an IMS providing enhanced originating services tothe NGCN user according to the peering model, and may also provideterminating services to the NGCN user.

The NGCN user generates an originating request while registered withinthe NGCN or while roaming in another network and sends it to the NGCNserver. The NGCN may apply provisioned services before forwarding therequest to the trunking home NGN via the standard peering (inter-IMS)interface to the NGN IMS (to an I-CSCF optionally via an IBCF) (202).

Upon receipt of the originating request, according to a new procedure,the I-CSCF determines if the request is a candidate for originatingservices according to local policy (203). Policy may specify, forexample, that all originating requests are candidates, that alloriginating requests received at a specific IBCF or I-CSCF arecandidates, or that all requests from a specific NGCN server arecandidates. If the I-CSCF determines that the request is a candidate fororiginating services, it sends a standard query to the HSS using thecontents of the P-Asserted-Identity (the identity of the calling party)(204).

Otherwise, if the I-CSCF determines that the request is not a candidatefor originating services, it routes the terminating request based on theRequest-URI (205).

According to a new procedure, the HSS may be provisioned with anoriginating-services-flag as a new element of the profile dataassociated with the PUID or wildcard PUID associated with theP-Asserted-Identity. This flag is provisioned in the HSS for eachsubscriber whose NGCN is interconnected via the peering model and who isto receive enhanced originating services. Upon receipt of the query fromthe I-CSCF, the HSS 1) follows the procedure already defined within FIG.3 to determine whether to return S-CSCF information to the I-CSCF, 2)includes an originating-services-flag in the response if it isprovisioned in the HSS for the PUID, and 3) returns the response to theI-CSCF (206). Note that the HSS does not know the purpose of the queryand may return the originating-services-flag under other conditions(e.g., for terminating requests), in which case it is ignored.

According to a new procedure, if the response from the HSS includesS-CSCF information and also includes the originating-services-flag, thenthe I-CSCF forwards the request to the assigned S-CSCF (207). The I-CSCFincludes the “orig” parameter (an existing IMS parameter) in theforwarded request to indicate to the S-CSCF that originating servicesare to be applied.

According to normal procedures, the S-CSCF downloads the profile for thePUID from the HSS (if it has not already been downloaded) and forwardsthe request to any application servers identified by unregistered filtercriteria, to apply appropriate originating services (208). After allapplication servers have been visited by the request, the S-CSCFforwards the request to the Request-URI (called party) (209). Thatconcludes this branch of the procedure, supporting the third case(enhanced originating services in the peering model).

Otherwise, if the response from the HSS either does not include S-CSCFinformation or does not include the originating-services-flag, then theI-CSCF begins normal I-CSCF procedures to route the request based on theRequest-URI (210).

With small changes to existing IMS procedures, this invention allows forapplication of enhanced originating services for NGCN usersinterconnected via the peering model based only on provisionedsubscriber data in a highly scalable manner.

Referring now to FIG. 5, in the fourth case (roaming service in thesubscription and peering models), the NGCN assigns to its users a SIPregistrar name whose domain is assigned within public DNS to the roaminghome NGN (301). This same domain resolves to the NGCN itself within theNGCN private DNS to enable the NGCN user to register for services fromits NGCN when not roaming. The roaming home NGN is an IMS that assignsan entry point into itself for SIP registration requests from roamingNGCN users in visited NGNs into which they roam. This entry point is thesame one used by roaming NGN users.

Following standard IMS procedures upon receipt of a registrationrequest, the I-CSCF in the NGN queries the HSS with the contents of theregistering AoR (address of record or PUID in the From header) (302).

According to a new procedure, each public identity assigned to a NGCNuser with roaming capability is provisioned within the HSS with analternate-registrar. The alternate-registrar contains the address atwhich the NGCN server can be reached with registration requests.

Since there is a potential for conflict between SIP registrationrequests from roaming NGCN users and registration requests directly fromthe NGCN (in the case where the NGCN using the subscription model mayregister on behalf of its users with the NGN), the HSS must be able todistinguish between these cases. The NGCN and NGN may, for example,assign unique PUIDs or PUID types to distinguish these cases.

According to a new procedure, upon receipt of the query from the I-CSCFfor a public identity associated with the NGCN, the HSS determineswhether the public identity has roaming capability (303). If so, thenthe HSS is provisioned to return the alternate-registrar (the NGCNserver address) instead of S-CSCF data (304).

Otherwise, if the HSS instead receives a query from the I-CSCF for apublic identity without roaming capability, the HSS is provisioned toreturn S-CSCF data according to normal procedures (305).

Next, the I-CSCF determines whether it has received S-CSCF data or thealternate-registrar from the HSS in response (306). In the event theI-CSCF receives S-CSCF data, it follows normal procedures to forward therequest to the S-CSCF (307). This is the case of normal NGN UEregistration. Otherwise, if the I-CSCF receives the alternate-registrarfrom the HSS according to a new procedure, the I-CSCF forwards theregistration request to the alternate-registrar instead of an S-CSCF(308).

According to a new procedure, the alternate-registrar and certain IMSnodes on the path need to populate the SIP path and service-routeheaders correctly so that subsequent originating and terminatingrequests follow the same path between the NGCN and the roaming UE (309).

With small changes to existing IMS procedures, this invention allows theroaming home NGN to properly route registration requests from roamingNGCN users to the NGCN based only on provisioned subscriber data in ahighly scalable manner.

The main advantage is that the terminating, originating and roamingscenarios listed above can be supported efficiently via small changes inprovisioned subscriber data and via small enhancements to generic IMSprocedures. Without this new solution, one would need to dedicate newfunctional entities to the specific routing and header manipulationtasks required in these scenarios. This default approach does not scaleup as well when supporting many NGCNs.

FIGS. 6-13 illustrate call flow diagrams to help further describe theoperation of the exemplary methods described above. Like referencenumerals apply to similar network elements throughout the various callflows.

As an example of the roaming procedure described in FIG. 5, FIG. 6illustrates a registration call flow from an NGCN user (402) that isroaming in a visited NGN (NGN B). The roaming user 402 needs to registerwith the SIP Proxy server 416 in its home NGCN in order to continuereceiving the same set of services as when it is at home (not roaming).

While roaming into a visited NGN B, the NGCN user 402 follows thestandard IMS procedure to discover a P-CSCF 404 in the visited NGN B.The NGCN user 402 sends the SIP REGISTER request to the P-CSCF 404 (step1). The SIP registrar name in the Request-URI is assigned by its homeNGCN. Within the public DNS, the assigned SIP registrar name resolves toan entry node—the IBCF 408—in the roaming home NGN (NGN C) (steps 2 &3). (The same domain name resolves to the NGCN itself within the NGCNprivate DNS to enable the NGCN user to register for services from itsNGCN when not roaming.) Following the existing IMS procedure, the IBCF408 forwards the request to the I-CSCF 410 (step 4), which then performsCx query with HSS 412 (step 5) to determine where to route the request.In accordance with aspects of the present invention (as shown in FIG.5), NGN C (roaming home) is provisioned in the HSS 412 with anAlternate-Registrar for NGCN user 402 that has roaming capability. Also,the Cx UAA query is enhanced to return the Alternate-Registrar for NGCNuser with roaming capability (step 5). For NGCN users without roamingcapability, the HSS 412 returns the S-CSCF name as usual in the Cx UAAmessage. The I-CSCF 410 is enhanced to rewrite the Request-URI using theAlternate-Registrar and forwards the Register request to the SIP Proxyserver 416, traversing IBCF 414 (steps 6 & 7). Enhancing the existingIMS registration procedure, each SIP stateful proxy server, P-CSCF 404,IBCF 408 and IBCF 414, inserts itself in the Path header, which will beused by the SIP Proxy server 416 to construct the terminating route andto forward terminating calls to the roaming user 402, traversing IBCF414, IBCF 408, and P-CSCF 404.

The SIP Proxy server 416 (acting as the SIP registrar) processes theREGISTER request, establishes the binding for the roaming user 402, andsends 200 OK to the roaming user 402 for successful registration. Whiletraversing the SIP servers, each SIP stateful server, the SIP Proxyserver 416, IBCF 414, IBCF 408, and P-CSCF 404, inserts itself in theService-Route header in the 200 OK response. The Service-Route headerwill be used by the roaming user 402 to construct the Route header whenit originates a call to ensure the call will be routed to the SIP Proxyserver 416. Optionally, SUBSCRIBE/NOTIFY of registration event may beused to allow the SIP Proxy server 416 (the SIP registrar) to notify theSIP servers (IBCF 414, IBCF 408 and P-CSCF 404) and the roaming user 402when the user 402 registration status (e.g., network-initiatedderegistration) changes.

To demonstrate how a roaming NGCN user originates a request, FIG. 7illustrates a call flow for call origination from an NGCN user (402)roaming to a visited NGN (NGN B). As a result of successful registration(shown in FIG. 6), the roaming user 402 constructs the Route header fromthe Service-Route header received in the 200 OK (REGISTER) response.Following standard IMS procedure, the INVITE request will be sent usingthe Route header and will traverse the P-CSCF 404, IBCF 408 and IBCF414, and reach the SIP Proxy server 416 in the home NGCN. The SIP Proxyserver 416 will then follow the normal call origination procedure andforward the request to the entry IBCF 418 in the trunking home NGN A.This allows the roaming user 402 to receive the same set of originatingservices as when it is not roaming.

As an example of the origination procedure of FIG. 4, FIG. 8 illustratesa call flow for normal NGCN origination for peering-based businesstrunking. It is applicable both when a NGCN user is at home (notroaming) and when a NGCN user is roaming. For the roaming case, FIG. 8is a continuation from FIG. 7.

When an NGCN user originates a call, the SIP Proxy Server 416 forwardsthe INVITE request to the entry point—the IBCF 418—in the trunking homeNGN (NGN A). Each NGCN is assigned with a trunking home NGN. The IBCF418 forwards the request to the I-CSCF 420. In accordance with aspectsof the present invention, the I-CSCF 420 invokes the Cx LIR query to theHSS 422 for the calling party (step 8). The calling party Cx query isinvoked based on local policy, either for every call, or per NGCNdetermined by the Service Level Agreement (SLA). A new AVP,originating-services-flag, is included in the response when the PublicUser Identity (PUID) in the Cx LIR query has originating servicesprovisioned in the HSS 422.

If originating services are provisioned for the PUID received in the CxLIR query, then the HSS 422 responds with the originating-services-flagand the S-CSCF name (step 8 a) in the Cx LIA response, else theoriginating-services-flag is not included in the response (step 8 b).

If the originating-services-flag is present and the S-CSCF name ispresent, then the I-CSCF 420, performing origination processing,forwards the request to the S-CSCF 424 for originating services (step 9a). In steps 10 a-12 a, the S-CSCF 425 follows the standard IMSprocedure and invokes originating services for the calling party. If theoriginating-services-flag is not present, the I-CSCF 420 starts normaltermination processing based on the Request-URI (step 9 b).

FIG. 9 illustrates a call flow for normal NGCN origination forsubscription-based business trunking. Note that for subscription-basedbusiness trunking solution, there is no impact to the existingoperation. For NGCN users that are “subscription based,” the HSS 422 isnot provisioned with Orig-Service-Flag or Alternate-Contact. The callflow is applicable for NGCN users that are at home (not roaming) and forNGCN users that are roaming. For the roaming case, FIG. 9 is acontinuation from FIG. 7.

To demonstrate how a roaming NGCN user receives a terminating request,FIG. 10 illustrates a call flow for call termination to an NGCN user(402) that is roaming in a visited NGN (NGN B). By definition, a calldestined to a NGCN user is first routed to its trunking home NGN A.After the NGN A invokes any IMS terminating services (detailed in FIG.11-13), it forwards the request to the SIP Proxy server 416, possiblytraversing the IBCF 430 (step 2).

The SIP Proxy server 416 (SIP registrar) knows that the terminatingparty (user 402) is roaming based on the registration process shown inFIG. 6. The SIP Proxy server 416 constructs the Route header using thePath header saved from the registration process and forwards the INVITEto the roaming user 402, traversing IBCF 414, IBCF 408, and P-CSCF 404.

As an example of the termination procedure of FIG. 3, FIG. 11illustrates a call flow for a first alternative for normal terminationto an NGCN user for peering-based business trunking (option1—re-target). The INVITE request arrives at the entry node—IBCF 432—inthe trunking home NGN (NGN A) for the terminating party (step 1).Following standard IMS procedure, the IBCF 432 forwards the request tothe I-CSCF 434 (step 2), which then performs Cx LIR query to HSS 422 forthe called party (step 3). If the HSS 422 is provisioned withunregistered originating or terminating services for the called party(with a public user identity) or if the corresponding public useridentity is shared by multiple private user identities, the HSS 422returns the S-CSCF name (step 5 a) in Cx LIA; otherwise, the HSS 422returns Alternate-Contact in accordance with aspects of the presentinvention. Optionally, the HSS 422 can also be provisioned to return anindication whether the loose-route or retarget option should be used fortermination routing.

In the case where the HSS 422 returns S-CSCF name (step 5 a), the I-CSCF434 follows the standard procedure and forwards the request to theS-CSCF 436. The S-CSCF 436 queries the HSS 422 to download a serviceprofile for the called party (step 7 a). The HSS 422 (step 8 a) returnsthe service profile, the Alternate-Contact and optionally an indicationwhether the loose-route or retarget option should be used for this NGCNuser. After invoking services for the called party based on standardprocedure (step 9 a), the S-CSCF 436 uses the Alternate-Contact receivedfrom HSS 422 (from step 8 a) to rewrite the Request-URI (retargetoption) and forwards the INVITE to the SIP Proxy server 416, traversingIBCF 438 (step 10 a and 11 a). The S-CSCF 436 chooses the retargetoption either according to provisioned policy or due to receipt of aretarget indication from HSS 422.

In the case when the HSS 422 returns an Alternate-Contact (step 5 b),the I-CSCF 434 rewrites the Request-URI using the Alternate-Contact(retarget option) and forwards the INVITE to the SIP Proxy server 416,traversing the IBCFy 438 (steps 6 b and 11 a). The NGCN user receives noenhanced services from the NGN in this case.

As a further example of the termination procedure of FIG. 3, FIG. 12illustrates a call flow for a second alternative for normal terminationto an NGCN user for peering-based business trunking (option2—loose-route). The procedures are the same as described as in FIG. 12,with the following exceptions. The HSS 422 optionally returns aloose-route indication rather than a retarget indication in step 5 b orstep 8 a. In step 10 a the S-CSCF 436 uses the loose-route option: itdoes not rewrite the Request-URI; instead, it populates two Routeheaders, the first one is the IBCF 438 and the second theAlternate-Route. Similarly, in step 6 b, the I-CSCF 434 uses theloose-route option: it does not rewrite the Request-URI; instead, itpopulates two Route headers, the first one is the IBCF 438 and thesecond the Alternate-Route.

FIG. 13 illustrates a call flow for normal termination to an NGCN userfor subscription-based business trunking. Note that for thesubscription-based business trunking solution, there is no impact to theexisting operation. For NGCN users that are “subscription based,” theHSS 422 is not provisioned with an alternate-contact.

The above description merely provides a disclosure of particularembodiments of the invention and is not intended for the purposes oflimiting the same thereto. As such, the invention is not limited to onlythe above-described embodiments. Rather, it is recognized that oneskilled in the art could conceive alternative embodiments that fallwithin the scope of the invention.

We claim:
 1. A method of providing roaming service for a user in a NextGeneration Network (NGN), the method comprising: assigning to one ormore users in a Next Generation Corporate Network (NGCN) a SessionInternet Protocol (SIP) registrar name whose domain is assigned within apublic Domain Name System (DNS) to a roaming home NGN; and within asubscriber database, provisioning a public user identity (PUID) assignedto an NGCN user having roaming capability with an alternate registrar,wherein the alternate registrar contains an address at which the NGCNserver can be reached with a registration request message.
 2. The methodof claim 2, further comprising: receiving a registration request messagefor a particular PUID; determining whether the particular PUID hasroaming capability; in response to determining the particular PUID hasroaming capability, forwarding the alternate registrar instead ofServing Call Session Control Function (S-CSCF) data in a responsemessage; forwarding the registration request message to the address ofthe alternate registrar instead of an S-CSCF.
 3. The method of claim 2,further comprising a network server that forwards the registrationrequest or response message populating one or more SIP path and serviceroute headers in the registration request message and the responsemessage according to standard SIP procedures so that a subsequentoriginating or terminating request message follows a same path betweenthe alternate registrar in the NGCN and a roaming user.
 4. The method ofclaim 2, wherein the home domain provisioned in the public DNS to directthe registration request message to the roaming home NGN is insteadprovisioned within the DNS of the NGCN to direct the registrationrequest directly to the alternate registrar within the NGCN when theNGCN user is receiving IP service within the NGCN.
 5. The method ofclaim 2, wherein the roaming home NGN comprises an Internet ProtocolMultimedia Subsystem (IMS) that assigns the same entry point into theIMS for SIP registration request messages from roaming NGCN users androaming NGN users being served in one or more visited NGNs, and whereinprocedures followed by a visited NGN for handling roaming NGCN users androaming NGN users are the same.
 6. The method of claim 1, furthercomprising: assigning to one or more users in a Next GenerationCorporate Network (NGCN) a public user identity (PUID) that is known toa trunking home NGN and has a domain assigned to the trunking home NGN;provisioning the subscriber database with an originating services flagrepresenting profile data associated with the PUID of the one or moreNGCN users whose NGCN is interconnected via a peering model and who isto receive enhanced originating services.
 7. The method of claim 6,further comprising: receiving an originating request message from aparticular NGCN user having a PUID; determining whether the originatingrequest message from the particular NGCN user is a candidate fororiginating services according to a local policy; in response todetermining whether the originating request message from the particularNGCN user is a candidate for originating services, sending a query to asubscriber database using the PUID of the particular NGCN user;forwarding the originating services flag for the PUID of the particularNGCN user in a response message to an Interrogating Call Session ControlFunction (I-CSCF); determining whether the response message furthercomprises Serving Call Session Control Function (S-CSCF) information forthe PUID of the particular NGCN user; in response to determining whetherthe response message further comprises S-CSCF information for the PUIDof the particular NGCN user, forwarding the request message to theappropriate S-CSCF.
 8. The method of claim 7, wherein the trunking homeNGN comprises an IMS providing enhanced originating services to an NGCNuser according to a peering model.
 9. The method of claim 7, wherein thelocal policy specifies that one more originating requests received at aspecific IBCF or I-CSCF are candidates, or that requests from a specificNGCN server are candidates.